Woooo boy, this is a fun one.

We're supposed to check against these echo = FALSE mistakes explicitly, because we agree that this is a common error and the message is confusing. We have written custom code for this! And also, how is that invalid YAML even making it to knitr? Why aren't we catching this?!

Oh. Ohhh. Tree-sitter.

A few months ago, we made the change to parse all of our yaml with tree-sitter (including in the CLI), so that we would have uniformity between the parses generated in the IDEs and the ones in the CLI.

I used to think that was a good idea, but I didn't realize one of the side effects. But now we are more tolerant of bad parses in our YAML chunks. So tree-sitter is happy to report that

is a valid YAML object. But of course it's not, as a quick trip to http://www.yamllint.com/ will show you. In addition, it says that our YAML object is, in JSON notation, { "label": "math", "echo = false": null }. Then, when we turn to YAML validation, of course this passes, because we have nothing to say about a echo = false key 🤦.

Worse yet, it doesn't look that the tree-sitter API can actually distinguish between a partial parse that emitted something but with an error, and a full parse that emitted something that is actually a valid parse.

We use tree-sitter in interactive mode in the IDEs, and currently we have a single codebase to parse code cells, both in the IDE and not. If we drop tree-sitter, then we lose error tolerance during completions as users type. That doesn't work

We could say that echo = false will never be a valid key in our YAML. I'm pretty sure we won't want to ever do it, but:

It turns out that yaml does allow spaces in its keys, if the keys are quoted. So this is valid YAML:

and has the same JSON representation as the invalid one from tree-sitter. So if we disallow spaces in keys, we fundamentally disallow some (deeply weird) yaml that someone might want to eventually write. I think this is my least bad idea to fix the problem.